[こんな時どうする]CloudFrontのログが出力されない時の確認と対応事例

こんにちは、臼田です。

皆さん、AWSと仲良くしていますか？(挨拶

今回は実際にお問い合わせいただいた内容の中で参考になりそうなものを記事にしてみました。事象に対する対応の仕方と、AWS上でのトラッキングの手法の両面で共有します。

CloudFrontのログがS3に出力されない

今回は「CloudFrontのログが以前は出力されていたのに、いつの間にかS3に出力されなくなった」というご相談に対する調査と対応を行いました。

CloudFrontの他にALBもそうですが、AWSのサービスからS3にログを出力する際には実はいろいろ必要な条件がありますが、気にしていないと意識しなくても出来てしまうことからあまりその条件が知られていません。このあたりも踏まえて見ていきましょう。

事象の確認

「いつの間にか出力されなくなっていた。最初は出力されていることを確認した。おそらく何かの設定を変更したのが原因だろうが、誰が何をしたかはわからない。」

今回はこんな状況です。それでは状態を確認しに行きます。

指定されたCloudFrontの設定からどのS3バケットにログを出力する設定になっているか確認します。

CloudFrontのディストーションの詳細画面General一番下にLog Bucket項目があります。少なくともこれが設定されているのでCloudFront自体の出力設定はされている状態です。場合によっては上の方のLog Prefixも意識することになるので余力があればこちらも確認しましょう。

続いてS3バケット側の状態を確認します。

ログが出力されなくなったとのことなので、いつからそうなったのかを確認します。

ログの出力先のプレフィックスを開いて、最終更新日時でソートします。一番上に表示された時間を確認します。

AWS Configでトラッキング

それではこの時間に何があったのか、変更履歴を管理する我らが守護神AWS Configを確認していきます。もちろんConfigで記録されていることが前提です。もし設定していない方がいたら今すぐ設定しましょう。

AWS Configはとりあえず有効にしよう

AWS Configのリソース画面で該当のバケットを確認します。リソースの種類にはS3: Bucketを入れ、リソース名を入れて検索します。出てきたリソース識別子をクリックします。

リソース詳細画面から「設定タイムライン」を押します。

設定タイムラインの中で上記で確認した最終ログ出力時間に近いものの変更を確認します。

変更内容の差分が確認できます。今回はAccessControlList(バケットACL)の1つの設定が削除されていました。この設定が今回の要因です。ちなみにこの下の方にはCloudTrailのログが表示され、どのユーザがいつ操作したかが確認できます。

CloudFrontのログ出力の仕組み

削除されたidで検索してもわかりますが、CloudFrontのログ出力の設定は下記に記載があります。

アクセスログの設定および使用 - Amazon CloudFront

「ロギングの設定およびログファイルへのアクセスに必要なアクセス許可」項目に書いてありますが、CloudFrontのログ出力は「awslogsdelivery アカウント」から行われており、ここからのアクセスを許可する必要があります。

自分のアカウントからログを出力するわけではないので、バケットACLにて明示的に許可する必要があります。このawslogsdeliveryアカウントのidが先程のc4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0です。

ただ、マネジメントコンソールではCloudFrontからログを出力する設定を行った際にバックグラウンドで自動的にこの設定が追加されるので、普段は意識することがないです。しかしながら、ふとS3バケットのACLを見てみると勝手に第三者からのアクセス権限が増えているので、誰かが間違えたと判断したりしてとりあえず消してしまうということはよくあります。よく見ることになるidなので覚えておいたほうがいいかもですね。

該当ガイドにはリカバリー方法が2種類書かれています。一度ログの出力設定を無効化して再有効化するか、手動で追加するかです。

もうログが出力されていない状況を考えると、再有効化の方が間違いなくできるのでこちらのほうが安全だと思います。

まとめ

今回はCloudFrontのログが出力されない事象について調査して対応した内容をまとめました。

単純に原因と対応方法を書くだけではなく、どのように調査したかを共有することにより、違う事象でも同じような対処方法を利用できると思ったのでそのようなコンセプトで書いてみました。

つまりAWS Configは守護神なので絶対に有効化しておきましょう。